[レポート]  CON316: AWS Fargateでのコンテナワークロードの保護 #reinvent

[レポート] CON316: AWS Fargateでのコンテナワークロードの保護 #reinvent

Clock Icon2018.11.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

本記事はAWS re:Invent 2018のセッション「CON316 - [REPEAT] Securing Container Workloads on AWS Fargate」のレポートです。

AWS Fargate makes it easy to run containers without needing to provision or manage servers. But how do you secure workloads without access to the host? In this session, we explore the security controls and best practices for securing containers running on AWS Fargate. We cover networking setup, IAM, and the AWS and third-party tools you can use to deploy a secure, scalable cluster with AWS Fargate.

スピーカーはAWSのテクニカルアカウントマネージャー、Theodore Salvo。

レポート

コンテナイメージ
 そのコンテナイメージを知る
  誰が作ったのか?どこから来たのか?
 イメージのタグ/digitsを選ぶ
 Scratch imageから作る
  ベースOSのみ、シンプルでセキュア
  スクラッチイメージから作ってる人?→少数
  スクラッチイメージであればアプリケーションとConfigに注力出来る

コンテナレジストリ
 プライベートレジストリ
  信頼性は自分たちで確保
  DockerレジストリやECRからイメージを取得し管理
 パブリックレジストリ
  信頼性は無し、ただし公式リポジトリは除く
  公式リポジトリが最も信頼出来る
 マーケットプレイスレジストリ
  信頼性はともかくverifyはされている
  作成もメンテナンスもベンダーが行う
 86%のイメージはUSER lineを使っておらずデフォルトでrootで動作する

ネットワークセキュリティ
 VPCを変更する必要無し
 ENIを通じてタスクと通信する
 タスクごとにセキュリティグループが独立
 タスクのネットワークはCSIプラグインを使用
 ネームスペースもタスクごとに独立

認証と認可
 タスクごとにロールが設定
 タスクから他のAWSサービスを利用
 ユーザーはIAMによってアクセスコントロール
  IAMの権限に従ってクラスタやタスクを操作
 タスクを実行するロール
  ECS/Fargateが利用
  コンテナイメージのPull/Publishを実行

機密情報の利用
 環境変数の場合
  暗号化無し
  認証/認可無し
  機密情報のローテーションは静的
 Systems Manager Parameter Storeの場合
  暗号化はKMSで実行
  認証/認可はIAMでコントロール
  機密情報のローテーションは静的
 Secrets Managerの場合
  暗号化はKMSで実行
  認証/認可はIAMでコントロール
  機密情報のローテーションを動的に行うことが出来る
 Secrets Managerがオススメ
  コンテナからAPIで叩いて機密情報を取得
  コンテナのセキュアな再利用が簡単に可能

実行中の保護
 EC2の場合
  ユーザーからEC2へのアクセスをFirewall/Security groupで保護
  アンチマルウェアはEC2にて実行
 ECS/Fargateの場合
  ユーザーからのアクセスはFirewall/Security groupで保護
  セキュリティエージェントは?2つの方法がある
   各コンテナにセキュリティエージェントをインストール
   セキュリティエージェント専用のコンテナから他のコンテナをチェックする(Sidecar container)

Advanced features
 Linuxのケーパビリティの削減/削除
  OSの機能は出来るだけ削ったほうがコンテナとしてはセキュア
  OSの機能の追加は出来ない
  コンテナへの特権も持たせない
 ネームスペース
  プロセス、CPU、メモリを名前で指定
  クラスタレベルで独立してネームスペースを分割
 リソース制限
  Elasticsearch等メモリを多く使うコンテナが他のコンテナに影響を与えないようにリミットの設定が可能
  ユーザーごとに制限が可能
  ソフトリミットまたはハードリミット
 Read onlyコンテナ
  例えばWebサーバ
   コンテンツが変わったら新しいコンテナを作成
  コンテナをリードオンリーとリードライトでレイヤー分割
  リードオンリーなコンテナは共通化   

さいごに

Fargateでのセキュリティについて分かりやすく解説してくれたセッションでした。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.